home *** CD-ROM | disk | FTP | other *** search
/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / telecomm / fnordadl / fn132man.zoo / chapter.09 < prev    next >
Text File  |  1991-09-02  |  18KB  |  417 lines
  1.  
  2.  
  3. Chapter 9:  Doors                                                        126
  4.  
  5.  
  6.  
  7.  
  8. 9  Doors
  9.  
  10.  
  11.    The Fnordadel __door__  mechanism allows the  Sysop to provide access  to
  12. external programs  from within  the BBS, in  a controllable  fashion.   This
  13. allows things  like online  games,  additional file  transfer protocols,  or
  14. whatever you feel like.  This chapter describes the door mechanism.
  15.  
  16.  
  17.  
  18. 9.1  Defining Doors
  19.  
  20.    Doors  are defined  in  the  file `ctdldoor.sys',  which  lives  in  your
  21. #sysdir.  It is  a simple ASCII text file, editable with any text  editor or
  22. word processor that  will save in ASCII. It  is read into memory  by citadel
  23. when it  runs; if you  change the file  somehow while Fnordadel is  running,
  24. you'll have  to [Q]uit from the  BBS and re-run  citadel to make the  change
  25. take effect.
  26.  
  27.  
  28. 9.1.1  Format of ctdldoor.sys
  29.  
  30.    The `ctdldoor.sys' file  consists of any number  of lines (each of  which
  31. defines a separate door), in the following format:
  32.  
  33.       <door> <mode> <program-name> [command tail] [#comment]
  34.  
  35.    The fields  should be separated  by white-space (i.e.,  spaces or  tabs).
  36. The meanings of the individual fields are as follows:
  37.  
  38. door       The name that Fnordadel will use to refer to this  door.  It must
  39.            be unique among all the doors you have defined.
  40.  
  41. mode       The  set   of  permissions/restrictions  on   this  door.      It
  42.            consists of  a string of any  of these characters (although  some
  43.            combinations don't make sense):
  44.  
  45.            `u'        Anyone may use this door.
  46.  
  47.            `a'        Only  Aides,  Co-Sysops and  the  Sysop may  use  this
  48.                       door.
  49.  
  50.            `s'        Only Co-Sysops and the Sysop may use this door.
  51.  
  52.            `z'        Only the Sysop may use this door  (that's you usually,
  53.                       but  it could  also  be any  Sysop  logged in  at  the
  54.                       system  console,  or  who   has  supplied  the  system
  55.                       password to get into the Sysop menu).
  56.  
  57.            `c'        Only users on the system console may use this door.
  58.  
  59.            `m'        Only users on the modem may use this door.
  60.  
  61.            `d'        This door  must be  executed from  within a  directory
  62.                       room.
  63.  
  64.  
  65.  
  66. Chapter 9:  Doors                                                        127
  67.  
  68.  
  69.  
  70.  
  71.            `r'        For `d' above; the directory must be readable.
  72.  
  73.            `w'        For `d' above; the directory must be writable.
  74.  
  75.            `t'        The user may provide a command tail for this command.
  76.  
  77.            `n'        Pass the  user name  to this  command as  part of  the
  78.                       command tail (as the end of the tail).
  79.  
  80.            `x'        This door  is a  ``system'' door.   See Section  9.3.1
  81.                       [System doors], page 130.
  82.  
  83.            `v'        This door  is an  ``archiver'' door,  defining a  file
  84.                       archiver which  Fnordadel will use  to read the  table
  85.                       of  contents of  archive  files.   See  Section  9.3.2
  86.                       [Archiver doors], page 130.
  87.  
  88.            `p'        This  door is  a ``protocol''  door,  defining a  file
  89.                       transfer  protocol.     See  Section  9.3.3  [Protocol
  90.                       doors], page 131.
  91.  
  92.            `h'        This  door  will   be  executed  from  the   BBS  home
  93.                       directory   (i.e.       where   ctdlcnfg.sys   lives).
  94.                       Normally,  a door executed  in a  directory room  will
  95.                       be run from  that room's directory.  Some  doors don't
  96.                       like that, so this mode can be  set to correct things.
  97.                       If  the `l'  mode is  also present,  it will  override
  98.                       this mode.
  99.  
  100.            `i'        If present, this must  be the last mode.  The  rest of
  101.                       the mode  string is the  name of a  room to which  the
  102.                       door will be  linked.  The  door will only show up  in
  103.                       the `!?' list in that room, and  will only be runnable
  104.                       in  that room.    If the  room  name contains  spaces,
  105.                       replace them with `_' in the door declaration.
  106.  
  107.                       If  a  mode   string  ended  with  `iFoo_blort',   for
  108.                       example,  this particular  door is  tied  to room  Foo
  109.                       blort.   If Foo blort  is a directory room,  Fnordadel
  110.                       will make  the room's directory the working  directory
  111.                       for the door  when it is run.   The `i' mode  can't be
  112.                       used with the `l' mode, described next.
  113.  
  114.            `l'        If present,  this must  be the  last mode.   The  rest
  115.                       of  the mode  string is  the directory  to which  this
  116.                       command  will  be linked.     If a  mode  string  ends
  117.                       with  `lc:\bin',  for  example,  Fnordadel  will  make
  118.                       `c:\bin' the  current working  directory when  running
  119.                       this command.   The  `l' mode can't  be used with  the
  120.                       `i'  mode, described  above.   If  used  with the  `h'
  121.                       mode, `l' takes precedence.
  122.  
  123. program-name
  124.            The  full pathname,  including  the  filename extension,  of  the
  125.            program attached to this door.
  126.  
  127.  
  128.  
  129. Chapter 9:  Doors                                                        128
  130.  
  131.  
  132.  
  133.  
  134. command tail
  135.            The optional  command tail to pass  to this door upon  execution.
  136.            If  the door  allows a  user-supplied command  tail,  it will  be
  137.            appended to  this command  tail, and  user names (mode  character
  138.            `n') are appended after everything else.
  139.  
  140. comment    Also optional.  This field must be preceded by a  `#'.  It allows
  141.            you to put  in a short description  of what the door does,  which
  142.            users will see when they hit `!?'.
  143.  
  144.  
  145. 9.1.2  Example door definitions
  146.  
  147.    Here are some sample door definitions, some of which you  may want to use
  148. on your system:
  149.  
  150.       clog    u       e:\citutil\clog.tos     -t      # 3-column log reader
  151.       uclog   s       e:\citutil\clog.tos     -p      # log reader for Sysop
  152.       rz      udrt    c:\bin\rz.ttp                   # zmodem download
  153.       ez      udwt    c:\bin\sz.ttp                   # zmodem upload
  154.  
  155.    The  first   example  provides  a   quick  way  for   users  to  get   an
  156. up-to-the-minute quickie  listing of  the user log;  it will  print out  the
  157. names only, in three-column format.  (See `clog.man' for more on clog.)
  158.  
  159.    The second  example is for  Sysop and  Co-Sysop use only  (note the  mode
  160. string  of `s').    It runs  clog and  passes  it the  argument `-p'  (which
  161. enables the printing of passwords).  You'd use this  if someone forgot their
  162. password and  you wanted to  find out  what it was  (be careful of  hackers,
  163. though).
  164.  
  165.    The third example  implements Zmodem downloads  via the external  program
  166. `rz.ttp', which is kept in `c:\bin'.  It passes no  command tail of its own,
  167. but it  does allow  the user  to pass  a tail in,  so he  can specify  which
  168. file(s) he wants to download.
  169.  
  170.    The fourth  example implements  Zmodem  uploads.   Notice  that the  mode
  171. string consists of  `udwt'; the `w' means  that this door is only  usable in
  172. rooms which allow uploads.  Makes sense, right?
  173.  
  174.  
  175.  
  176. 9.1.3  Notes
  177.  
  178.   o In any  directory room, the ``current  directory'' (for the purposes  of
  179.     the  door program) is  always set to  be the  directory attached to  the
  180.     room, unless you use the link mode `l' to specify another directory.
  181.  
  182.   o User-supplied command tails  (enabled with `t' in the mode  string) will
  183.     be  scanned for occurences  of `\'  and `:' characters,  and these  will
  184.     be removed.    This is to  stop an unscrupulous  user from passing  full
  185.     pathnames  to,  say,  a file  transfer  program  and gaining  access  to
  186.     private information;  users will only be  able to access information  to
  187.     which they have normal Citadel access (by being in a directory room).
  188.  
  189.  
  190.  
  191. Chapter 9:  Doors